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Abstract 


IP Virtual Private Networks (VPNs) provide connectivity between sites 
across an IP/MPLS backbone. These VPNs can be operated using 
BGP/MPLS, and a single Provider Edge (PE) node may provide access to 
multiple customer sites belonging to different VPNs. 


The VPNs may support a number of customer services, including RSVP 
and Resource Reservation Protocol Traffic Engineering (RSVP-TE) 
traffic. This document describes how to support RSVP-TE between 
customer sites when a single PE supports multiple VPNs and labels are 
not used to identify VPNs between PEs. 


Status of This Memo 
This document is not an Internet Standards Track specification; it is 
published for examination, experimental implementation, and 


evaluation. 


This document defines an Experimental Protocol for the Internet 


community. This document is a product of the Internet Engineering 
Task Force (IETF). It represents the consensus of the IETF 

community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Not 


all documents approved by the IESG are a candidate for any level of 
Internet Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6882. 
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Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 


carefully, as they describe your rights and restrictions with respect 


to 


this document. Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


La 


Introduction 


Service Providers would like to use BGP/MPLS IP VPNs [RFC4364] to 
support connections between Customer Edge (CE) sites. As described 
in [RFC5824], these connections can be MPLS Traffic Engineered (TE) 
Label Switched Paths (LSPs) established using extensions to RSVP 
[RFC3209] for a number of different deployment scenarios. The 
requirements for supporting MPLS-TE LSP connections across BGP/MPLS 
IP VPNs are documented in [RFC5824]. 


In order to establish a customer MPLS-TE LSP over a BGP/MPLS IP VPN, 
it is necessary for the RSVP-TE control messages, including the Path 
and Resv messages described in [RFC3209], to be handled appropriately 
by the Provider Edge (PE) routers. [RFC4364] allows RSVP messages 
sent within a VPN’s context to be handled just like any other VPN 
data. In such a solution, the RSVP-TE component at a PE that sends 
messages toward a remote PE must process the messages in the context 
of the VPN and must ensure that the messages are correctly labeled. 
Similarly, when a message sent across the core is received by a PE, 
both labels must indicate the correct VPN context. 


Implementation of the standards-based solution described in the 
previous paragraph is possible, but requires proper support on the 
PE. In particular, a PE must be able to process RSVP messages within 
the context of the appropriate VPN Routing and Forwarding (VRF). 

This may be easy to achieve in some implementations, but in others, 
it is not so easy. 


This document defines experimental formats and mechanisms that follow 
a different approach. The documented approach enables the VPN 
identifier to be carried in the RSVP-TE protocol message so that 
there is no requirement for label-based VRF identification on the PE. 


The experiment proposed by this document does not negate the label- 
based approach supported by [RFC4364]. The experiment is intended to 
enable research into alternate methods of supporting RSVP-TE within 
VPNs. 


1. Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
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2. Motivation 


If multiple BGP/MPLS IP VPNs are supported at the same PE, new RSVP- 
TE extensions are required so that RSVP-TE control messages from the 
CEs can be handled appropriately by the PE. 


2.1. Network Example 
Figure 1 ("Customer MPLS TE LSPs in the context of BGP/MPLS IP VPNs") 
shows two VPNs supported by a core IP/MPLS network. Both VPNs have 
customer sites on the two PEs shown in the figure. The customer 


sites operate MPLS-TE LSPs. 


Here, we make the following set of assumptions: 


o VPN1 and VPN2 are for different customers. 
o CEl and CE3 are head-end routers. 
o CE2 and CE4 are tail-end routers. 
o The same address (e.g., 192.0.2.1) is assigned at CE2 and CE4. 
a gr a Customer MPLS-TE LSP for VPN1-------- > 
. |CE1|----|PE1|----|P1 |----- |P2 |----|PE2|----- |CE2|. 
(VPN1) (VPN1) 
| cCE3|------ + +-----—- |CE4 | 
(VPN2) (VPN2) 
KSSSesass Customer MPLS-TE LSP for VPN2-------- > 
VRF instance VRF instance 
<-Customer-> <---BGP/MPLS IP VPN---> <-Customer-> 
network network 


Figure 1: Customer MPLS TE LSPs in the context of BGP/MPLS IP VPNs 


Kumaki Experimental [Page 4] 


RFC 6882 Support for RSVP-TE in L3VPNs March 2013 


Consider that customers in VPN1 and VPN2 would like to establish 
customer MPLS-TE LSPs between their sites (i.e., between CEl and 
CE2, and between CE3 and CE4). In this situation, the following 
RSVP-TE Path messages would be sent: 


1. CEl would send a Path message to PE1 to establish the MPLS-TE 
LSP (VPN1) between CE1 and CE2. 


2. CE3 would also send a Path message to PE1 to establish the 
MPLS-TE LSP (VPN2) between CE1 and CE2. 


After receiving each Path message, PE1 can identify the customer 
context for each Path message from the incoming interface over which 
the message was received. PE1 forwards the messages to PE2 using the 
routing mechanisms described in [RFC4364] and [RFC4659]. 


When the Path messages are received at PE2, that node needs to 
distinguish the messages and determine which applies to VPN1 and 
which to VPN2 so that the right forwarding state can be established 
and so that the messages can be passed on to the correct CE. 
Although the messages arrive at PE2 with an MPLS label that 
identifies the VPN, the messages are delivered to the RSVP-TE 
component on PE2, and the context of the core VPN LSP (i.e., the 
label) is lost. Some RSVP-TE protocol mechanism is therefore needed 
to embed the VPN identifier within the RSVP-TE message. 


Similarly, Resv messages sent from PE2 to PE1 need an RSVP-TE 
mechanism to assign them to the correct VPN. 


3. Protocol Extensions and Procedures 


This section defines the additional RSVP-TE objects to meet the 
requirements described in Section 2. These objects are new variants 
of the SESSION, SENDER TEMPLATE, and FILTERSPEC objects. They act as 
identifiers and allow PEs to distinguish Path/Resv messages per VPN 
in the context of BGP/MPLS IP VPNs. Section 3.1 defines the new 
object types, and Section 3.2 defines the specific procedures for 
handling RSVP messages. 


3.1. Object Definitions 


This experiment will be carried out using the following private Class 
Types. This document identifies these Class Types as 
"C-Type = EXPn". 
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Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1 

Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type EXP2 

Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3 
Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type = EXP4 
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5 
Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6 


3.1.1. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SESSION Object 


The LSP_TUNNEL_VPN-IPv4 (or LSP_TUNNEL_VPN-IPv6) SESSION object 
appears in RSVP-TE messages that ordinarily contain a SESSION object 
and that are sent between the ingress PE and egress PE in either 
direction. This object MUST NOT be included in any RSVP-TE message 
that is sent outside of the provider’s backbone. 


The LSP_TUNNEL_VPN-IPv6 SESSION object is analogous to the 
LSP_TUNNEL_VPN-IPv4 SESSION object, using a VPN-IPv6é address 
([RFC4659]) instead of a VPN-IPv4 address ([RFC4364]). 


Experimenters MUST ensure that there is no conflict between the 
private Class Types used for this experiment and other Class Types 
used by the PEs. 


The formats of the SESSION objects are as follows: 
Class = SESSION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP1 


0 1 2 3 
O 2 3 AE V B79 0 L2 3A 56 T 8 9 0 P 3A e T 8790 1 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
VPN-IPv4 Tunnel Endpoint Address (12 bytes) | 
+ 


-+-+-+-+-+-+-+-+-+-+-+ ++ 

MUST be zero | Tunnel ID 
-+-+-+-+-+-+-+-+-+-+-+ +++ 
Extended Tunnel ID | 


+ 
| 
+ 
| 
+ 
| 
+ 
| 
+ 
| 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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Class = SESSION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP2 


0 1 2 3 
012345678901234567890123456789021 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


VPN-IPv6 Tunnel Endpoint Address (24 bytes) 


—+-+-4-+4+-4+-4-4+-4+-4-4-4+-4+-4+-4-4+-4+-4-4-4+-4-4-4+-4+-4+-4-4+-4+-4-4+-4+-4- 
MUST be zero Tunnel ID 
—+-+-4-4+-4+-4-4-4+-4-4-4+-4+-4+-4-4+-4+-4+-4-4+-4-4-4+-4+-4-4+-4+-4+-4-4+-4+-4- 


+—+—4+—4+—4+—4+—4+— 


| 
+ 
| 
Extended Tunnel ID (16 bytes) + 
| 
+ 
| 


+—+—4+—4+— + — + — + — + — + — + — + — GH 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The VPN-IPv4 or VPN-IPv6 tunnel endpoint address field contains an 
address of the VPN-IPv4 or VPN-IPv6 address family encoded as 
specified in [RFC4364] or [RFC4659], respectively. 


The Tunnel ID and Extended Tunnel ID are identical to the same fields 
in the LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6 SESSION objects as per 
[RFC3209]. 


aa 2% LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE 
Objects 


The LSP_TUNNEL_VPN-IPv4 (or LSP_TUNNEL_VPN-IPv6) SENDER_TEMPLATE 
object appears in RSVP-TE messages that ordinarily contain a 
SENDER_TEMPLATE object and that are sent between ingress PE and 
egress PE in either direction, such as Path, PathError, and PathTear 
messages. The object MUST NOT be included in any RSVP-TE messages 
that are sent outside of the provider’s backbone. 
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The format of the object is as follows: 


Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv4 C-Type = EXP3 


VPN-IPv4 Tunnel Sender Address (12 bytes) 


—+-+-4-4+-4+-4-4+-4+-4-4-4+-4-4-4-4-4+-4-4-4+-4-4-4+-4+-4-4-4+-4+-4-4+-4+-4- 
MUST be zero LSP ID 
—+-+-4-4+-4+-4-4-4+-4-4-4+-4+-4-4-4+-4-4-4-4+-4-4-4+-4-4+-4-4+-4+-4-4-4+-4- 


+—+—+—+—H+0 
+—+—4+—4+—+4+ 


ll 
(zal 
D< 
go] 
AS 


Class = SENDER_TEMPLATE, LSP_TUNNEL_VPN-IPv6 C-Type 


VPN-IPv6 Tunnel Sender Address (24 bytes) 


Ato tototitotititatatatititotititotititatatatititotitititititat- 
MUST be zero | LSP ID 
ea 


+—+—+—4+—4+—4+—4+—H40 
— + — + — + — + — + — + — +H 


The VPN-IPv4 or VPN-IPv6 tunnel sender address field contains an 
address of the VPN-IPv4 or VPN-IPv6 address family encoded as 
specified in [RFC4364] or [RFC4659], respectively. 


The LSP ID is identical to the LSP ID field in the LSP_TUNNEL_IPv4 
and LSP_TUNNEL_IPv6 SENDER TEMPLATE objects as per [RFC3209]. 
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3.1.3. LSP_TUNNEL_VPN-IPv4 and LSP_TUNNEL_VPN-IPv6 FILTER_SPEC Objects 


The LSP_TUNNEL_VPN-IPv4 (or LSP_TUNNEL_VPN-IPv6) FILTER_SPEC object 
appears in RSVP-TE messages that ordinarily contain a FILTER_SPEC 
object and that are sent between ingress PE and egress PE in either 
direction, such as Resv, ResvError, and ResvTear messages. The 
object MUST NOT be included in any RSVP-TE messages that are sent 
outside of the provider’s backbone. 


Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv4 C-Type = EXP5 


The format of the LSP_TUNNEL_VPN-IPv4 FILTER_SPEC object is 
identical to the LSP_TUNNEL_VPN-IPv4 SENDER_TEMPLATE object. 


Class = FILTER SPECIFICATION, LSP_TUNNEL_VPN-IPv6 C-Type = EXP6 


The format of the LSP_TUNNEL_VPN-IPv6 FILTER_SPEC object is 
identical to the LSP_TUNNEL_VPN-IPv6 SENDER_TEMPLATE object. 


3.1.4. VPN-IPv4 and VPN-IPv6 RSVP_HOP Objects 


The formats of the VPN-IPv4 and VPN-IPv6 RSVP_HOP objects are 
identical to the RSVP_HOP objects described in [RFC6016]. 


3.2. Handling the Messages 


This section describes how the RSVP-TE messages are handled. 
Handling of these messages assumes that, in the context of BGP/MPLS 
IP VPNs, the ingress and egress PES have RSVP-TE capabilities. 


3.2.1. Path Message Processing at the Ingress PE 


When a Path message arrives at the ingress PE (PE1l in Figure 1), the 
PE needs to establish suitable Path state and forward the Path 
message on to the egress PE (PE2 in Figure 1). Below, we describe 
the message handling process at the ingress PE. 


1. CEl sends a Path message to PE1 to establish the MPLS-TE LSP 
(VPN1) between CEl and CE2. The Path message is addressed to 
the eventual destination (the receiver at the remote customer 
site) and carries the IP Router Alert option, in accordance 
with [RFC2205]. The ingress PE must recognize the router 
alert, intercept these messages, and process them as RSVP-TE 
signaling messages. 
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When the ingress PE receives a Path message from a CE that is 
addressed to the receiver, the VRF that is associated with the 
incoming interface can be identified. (This step does not 
deviate from current behavior.) 


The tunnel endpoint address of the receiver is looked up in the 
appropriate VRF, and the BGP next hop for that tunnel endpoint 
address is identified. The next hop is the egress PE. 


A new LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object is 
constructed, containing the Route Distinguisher (RD) that is 
part of the VPN-IPv4/VPN-IPv6 route prefix for this tunnel 
endpoint address, and the IPv4/IPv6 tunnel endpoint address 
from the original SESSION object. 


A new LSP_TUNNEL_VPN-IPv4/IPv6 SENDER_TEMPLATE object is 
constructed, with the original IPv4/IPv6 tunnel sender address 
from the incoming SENDER_TEMPLATE plus the RD that is used by 
the PE to advertise the prefix for the customers VPN. 


A new Path message is sent containing all the objects from the 
original Path message, replacing the original SESSION and 
SENDER_TEMPLATE objects with the new 
LSP_TUNNEL_VPN-IPv4/VPN-IPv6 type objects. This Path message 
is sent directly to the egress PE (the next hop that was 
determined in Step 3) without the IP Router Alert option. 


Path Message Processing at the Egress PE 


we describe the message handling process at the egress PE. 


When a Path message arrives at the egress PE (PE2 in Figure 1), 
it is addressed to the PE itself and is handed to RSVP for 
processing. 


The router extracts the RD and IPv4/IPv6 address from the 
LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object and determines the 
local VRF context by finding a matching VPN-IPv4 prefix with 
the specified RD that has been advertised by this router into 
BGP. 


The entire incoming RSVP message, including the VRF 
information, is stored as part of the Path state. 
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4. The egress PE can now construct a Path message that differs 
from the Path message it received in the following ways: 


a. Its tunnel endpoint address is the IP address extracted from 
the SESSION object. 


b. The SESSION and SENDER TEMPLATE objects have been converted 
back to IPv4-type/IPv6-type by discarding the attached RD. 


c. The RSVP_HOP object contains the IP address of the outgoing 
interface of the egress PE and a Logical Interface Handle 
(LIH), as per normal RSVP processing. 


5. The egress PE then sends the Path message towards its tunnel 
endpoint address over the interface identified in Step 4c. 
This Path message carries the IP Router Alert option, as 
required by [RFC2205]. 


3.2.3. Resv Processing at the Egress PE 


When a receiver at the customer site originates a Resv message for 
the session, normal RSVP procedures apply until the Resv, making its 
way back towards the sender, arrives at the "egress" PE (it is the 
egress with respect to the direction of data flow, i.e., PE2 in 
Figure 1). Upon arriving at PE2, the SESSION and FILTER_SPEC objects 
in the Resv message, and the VRF in which the Resv was received, are 
used to find the matching Path state that was stored previously. 


The PE constructs a Resv message to send to the RSVP HOP stored in 
the Path state, i.e., the ingress PE (PEl in Figure 1). The LSP 
TUNNEL IPv4/IPv6 SESSION object is replaced with the same 
LSP_TUNNEL_VPN-IPv4/VPN-IPv6 SESSION object received in the Path 
message. The LSP TUNNEL IPv4/IPv6 FILTER_SPEC object is replaced 
with a LSP_TUNNEL_VPN-IPv4/VPN-IPv6 FILTER_SPEC object, which copies 
the VPN-IPv4/VPN-IPv6 address from the LSP TUNNEL SENDER_TEMPLATE 
received in the matching Path message. 


The Resv message MUST be addressed to the IP address contained within 
the RSVP_HOP object in the Path message. 


3.2.4. Resv Processing at the Ingress PE 


When the ingress PE receives a Resv message (the ingress with respect 
to data flow, i.e., PEl in Figure 1), the PE determines the local VRF 
context and associated Path state for this Resv message by decoding 
the received SESSION and FILTER_SPEC objects. It is now possible to 
generate a Resv message to send to the appropriate CE. The Resv 
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message sent to the ingress CE contains the LSP TUNNEL IPv4/IPv6 
SESSION and LSP TUNNEL FILTER_SPEC objects, which are derived from 
the appropriate Path state. 


3.2.5. Other RSVP Messages 


Processing of other RSVP messages (i.e., PathError, PathTear, 
ResvError, ResvTear, and ResvConf) generally follows the rules 


defined in [RFC2205]. The following additional rules MUST be 
observed for messages transmitted within the VPN, i.e., between the 
PES: 


o The SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects MUST be 
converted from LSP_TUNNEL_IPv4/LSP_TUNNEL_IPv6 [RFC3209] to 
LSP_TUNNEL_VPN-IPv4/LSP_TUNNEL_VPN-IPv6 form, respectively, and 
back again, in the same manner as described above for Path and 
Resv messages. 


o The appropriate type of RSVP_HOP object (VPN-IPv4 or VPN-IPv6) 
MUST be used, as described in Section 8.4 of [RFC6016]. 


o Depending on the type of RSVP_HOP object received from the 
neighbor, the message MUST be MPLS encapsulated or IP 
encapsulated. 


o The matching state and VRF MUST be determined by decoding the 
corresponding RD and IPv4 or IPv6 address in the SESSION and 
FILTER_SPEC objects. 


o The message MUST be directly addressed to the appropriate PE, 
without using the Router Alert Option. 


4. Management Considerations 


MPLS-TE-based BGP/MPLS IP VPNs are based on a peer model. If an 
operator would like to configure a new site to an existing VPN, 
configuration of both the CE router and the attached PE router is 
required. The operator is not required to modify the configuration 
of PE routers connected to other sites or to modify the configuration 
of other VPNs. 


4.1. Impact on Network Operation 
It is expected that the use of the extensions specified in this 


document will not significantly increase the level of operational 
traffic. 
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Furthermore, the additional extensions described in this document 
will have no impact on the operation of existing resiliency 
mechanisms available within MPLS-TE. 


5. Security Considerations 


This document defines RSVP-TE extensions for BGP/MPLS IP VPNs. The 
general security issues for RSVP-TE are described in [RFC3209], 
[RFC4364] addresses the specific security considerations of BGP/MPLS 
VPNs. General security considerations for MPLS are described in 
[RFC5920]. 


In order to secure the control plane, techniques such as the TCP 
Authentication Option (TCP-AO) [RFC5925] MAY be used authenticate BGP 
messages. 


To ensure the integrity of an RSVP request, the RSVP Authentication 
mechanisms defined in [RFC2747], and updated by [RFC3097], SHOULD be 
used. 
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